Method for rerouting a packet-mode data connection

ABSTRACT

A method for rerouting a packet-mode data connection, especially a frame relay network data connection, in which, traffic transmitted between two nodes is transferred from a first route to be disabled to a second, new route. In a rerouting situation, data packets to be transmitted to a new route are buffered, when needed, in a transmitter in order to perform checking concerning the route or to ensure the correct order of the data packets. In order to accomplish rerouting as fast as possible and with a minimum loss of data, the opposite end is notified of the need for buffering by sending a message, the contents of which depend on the rerouting situation in question.

This application claims benefit of international applicationPCT/FI95/00112, filed Feb. 28, 1995.

BACKGROUND OF THE INVENTION

The invention relates to a method for rerouting a packet-mode dataconnection.

In principle, the method of the invention can be applied in any packetswitched network but the invention is primarily intended for a FRnetwork (Frame Relay network) for which its features (the use ofbuffering) are very well suited. However, the invention can also be usedin a (generally faster) ATM (Asynchronous Transfer Mode) network, forexample.

Replacing previous packet network connections, Frame Relay is a packetnetwork technique for transmitting frames of varying lengths, a heavilystripped-down version of a nowadays generally used protocol (X.25) thatrequires a lot of processing. By stripping operations that have becomein a way unnecessary with time because of improvements in the quality ofthe transmission network, frame relay in the Frame Relay technique hasbecome faster and more efficient.

ATM is a new packet-switching technique in which the problems ofconventional packet networks have been solved by introducing shortpackets of a standard length (53 bytes) known as cells. Each cellcontains a payload part of 48 bytes and a header of 5 bytes in length.

However, in this connection the FR or ATM technology will not bedescribed any further as the method of the invention is not connected toany FR or ATM specific arrangements, but the node devices of the networkare only required to have an ability to buffer. Frame Relay service isgenerally described in the CCIT recommendation I.233, "Frame Mode BearerServices", a the related protocol recommendation Q.922. For a moredetailed description of the Frame Relay technique, a reference is madeto the article "An Overview of Frame Relay Technology", Data-proManagement of Data Communications, McGraw-Hill Incorporated, April 1991.A closer description of the ATM technology can be found, for example, inthe CCITT recommendation I.610, "B-ISDN operation and maintenanceprinciples and functions", CCITT Study Group XVIII Geneva, Jun. 9-19,1992, or in the recommendation I.361, "B-ISDN ATM Layer Specification",CCITT; ANSI T1.617 Annex D.

In packet networks, connections can be "protected" by having one or twoalternative routes between nodes in addition to the main route. In thiscase, traffic can be transferred from one route to another if necessary.One of the requirements of the ATM network is, for example, that theorder of the cells in the connection will remain invariable in thenetwork. Because the ATM headers of the data cells do not have asequence number to make the rearrangement of the cells possible, theconnection has to travel via the same route through the network.

Transferring traffic from one route to another leads very probably tochanges in the order of the cells and thus, loss of data, in case thedelay of the new route is smaller than that of the old route.

SUMMARY OF THE INVENTION

It is an object of the present invention to eliminate theabove-mentioned disadvantage and to achieve a method in which a virtualconnection transmitting packet-mode data is transferred from one routeto another as fast as possible with a minimum loss of traffic, even inconflict situations in which the nodes at the termination points of theroute have contradictory information about the routes in use.

The idea of the invention is to accomplish a dialogue which is based onmutual message exchange between the nodes, and on the basis of which thenodes will buffer data in their transmitters only when needed and also,until they can ascertain that they are transferring data to the sameroute so that the order of the packets at the opposite end will not bechanged. The opposite end is notified of the need for buffering in eachrerouting situation by a message exchange.

The method of the invention provides maximum probability that the packetdata will reach its destination and do so in the correct order. Trafficis lost only when an active route becomes physically faulty, andeventhen, only the traffic already transmitted in between the appearanceand detection of the fault is lost.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, the invention and its preferred embodiment aredescribed in more detail with reference to the example of theaccompanying drawing, in which,

FIG. 1 shows a part of a packet-switched network that has two possibleroutes between two nodes,

FIG. 2 shows a schematic structure of the nodes in the terminationpoints of the routes according to FIG. 1,

FIG. 3 shows the operation of a state machine for rerouting,

FIG. 4 shows the operation of a state machine for buffering, and

FIG. 5 shows the operation of a state machine for route testing.

DETAILED DESCRIPTION

The method of the invention is especially suitable for networks usingsemi-permanent virtual connections (PVC) in case:

a) traffic on a faulty active route has to be transferred to analternative route, or

b) traffic on an active route which is in order is directed to anotherroute.

In the following, alternative a) is called forced rerouting andalternative b), controlled rerouting. Controlled rerouting is performedeither when disabling a route for maintenance procedures or whenreturning from an alternative route to an ordinary route.

The ends of a virtual connection are often in different nodes far awayfrom each other. Thus, the different nodes control the ends of thevirtual connection independently.

FIG. 1 shows a network or a part of a network in which there are twopossible routes between subscribers A and B. Nodes of the network aredenoted by reference numerals 1 . . . 4 and alternative routes betweenthe nodes 1 and 4 are denoted by reference signs a-b and A-B. Thefollowing markings are used in the description:

subscriber A--the first party of the data connection

subscriber B--the second party of the data connection

a-b, A-B--bidirectional routes on which the data of subscriber A or Bcan be transmitted

a→b, A→B--unidirectional routes on which the data of subscriber A can betransmitted to subscriber B

b→a, B→A--unidirectional routes on which the data of subscriber B can betransmitted to subscriber A.

The method of the invention does not, as such, require of the internalstructure of the node anything else but the ability to buffer data.Thus, the internal structure of the node can vary in many ways dependingon the network in use. The node (1 or 4) can simply be similar to a FRnode (known per se), as shown in FIG. 2, in which a FR frame from asubscriber is received in an input buffer 15a, from which it is switchedfurther onto a router 16, which routes it onto a correct output buffer(15c or 15e). In this case (cf. FIG. 1), there are two trunk connections(to nodes 2 and 3) and one subscriber connection (buffers 15a and 15b).

A description is first given of forced rerouting that is a result offaults in the connection.

In the example, it is presumed that in an initial situation the routea-b is active. Forced rerouting starts when, for example, node 1 detectsthat the route a→b transmitting traffic is faulty (the node detects thatthe data link to the opposite end is not operating). The detection canbe based, for example, on a notification of the fault from the oppositeend. After a fault detection of this kind, node 1 immediately transfersthe traffic (the data packets to be transmitted) to a usable alternativeroute A→B and sends a notice of this to the opposite end (node 4) viathis new route. According to a more advantageous (more efficient)embodiment, the order is as shown above; the node first transfers thetraffic to be transmitted on an alternative route and only after that,sends said notice. (Rerouting is performed first so that no frame islost unnecessarily.)

If node 4 detects the fault at the same time as node 1, both nodestransfer the traffic to the route A-B simultaneously. Both nodes alsoreceive a notice from the opposite end of the transition of the othertraffic direction to the same bidirectional route that it has juststarted or is just starting to use. In this case, the nodes aresatisfied with these notices and forced rerouting is complete.

If node 4 does not detect the fault fast enough, it receives, as a firstindication of the fault on the route a-b, a notice, from an alternativeroute A-B of its own, of the transition of the opposite end to operateon this new route. (In the method of the invention the nodes are alsoconstantly listening to the routes that are in reserve.) At the latest,after receiving this notice, node 4 accepts all the incoming trafficfrom the route A-B and transmits it forwards to the subscriber. At thesame time, node 4 starts buffering the data packets to be transmitted toan active route b→a and also tests the condition of the route b→a. Thetesting can be conducted, for example, with a "ping-pong" type ofmessage exchange which has the advantage that it will thus allow thecondition of the whole connection to be tested. After finding the routeb→a to b faulty, node 4 sends the buffered frames via a new route B→Aand continues to direct traffic to the route B→A. In this case forcedrerouting is complete.

In a possible conflict situation, in which the different ends (nodes 1and 4) of a virtual connection want to transfer the traffic to differentroutes, the conception of one node is always dominating. The messagesused for managing the virtual connection have a field in which the rankof different ends is shown (the position of the field in a frame dependson the protocol in use). This identifier can, for example, be a nodenumber in the network, in which case the node with a higher number, forexample, dominates the node with a lower number.

A conflict situation is created if the virtual connection betweensubscribers A and B also has a third route a'-b' (not shown in thefigure) that is configured in node 1, for example, to be a secondaryalternative route, but is configured in node 4, to be a primaryalternative route. In this case, the operation of node 4 depends onwhether it is a dominating or an obeying node.

In case node 4 is dominating, it sends the buffered packets via its ownprimary alternative route a'-b' and commands the opposite end to usethis route, too. Thereafter, the obeying node 1 transfers the traffic tothe route a'-b' by means of controlled rerouting, by which the nodesmake sure, by using a special return-from-route notice and anacknowledgement in response to it, that all the data messages havearrived at the opposite end before transferring the transmission to anew route. Controlled rerouting and the message exchange used thereinare described in more detail below.

If node 4 detects during forced rerouting described above, that thefault has disappeared in the original route b→a, a conflict situation iscreated, in which the operation of the node 4 again depends on whetherit is a dominating or an obeying node. If a dominating node detects thatthe original route is in order again, it stops the buffering of the datapackets to be transmitted to the virtual connection, transmits thebuffered packets via the original route, and commands the opposite endto use the original route by sending it a management message to thiseffect. In this case, it is most advantageous to keep the order ofthings such that the management message is sent first and the datapackets only after that. If an obeying node detects that the originalroute is in order again, it will not transfer the traffic directly backto the original route but acts as in controlled rerouting, (discussedherein below) ensuring first by means of a message exchange that all thedata packets have arrived from the route to be disabled to the oppositeend before new data packets are transmitted on the new route.

In one (fast) embodiment of the invention, the above-described forcedrerouting is made even more effective in such a way that the nodedetecting the fault first commands the opposite end, by sending aspecial forced rerouting message, to transfer the traffic to a new routeimmediately, that is, wholly without buffering. The node that hasreceived this command will test the condition of the old active routeonly after transferring the traffic from old active route.

When both ends of the virtual connection detect at the same time thatthe active route is faulty, they send forced rerouting commands via thenew active routes they have selected. The nodes select different routes,for example, when their routing information is divergent, as describedabove in connection with the route a'-b'. In this case, after receivinga forced rerouting command, the obeying node is forced to transfertraffic from the route it selected, to the route the dominating nodeselected, without any safety measures (buffering). The danger of changesto the order of the data packets is then quite evident.

The above-described fast forced rerouting is therefore subject to faultsif the routing data at the different ends of the virtual connection arecontradictory. If the routing data of the virtual connection is inorder, this method is, however, quite safe. An advantage of thisembodiment is its speed, since the data packets are not buffered.

Forced rerouting and its different embodiments are described above. Inthe following, an alternative method is described, that is, controlledrerouting which does not involve a fault situation as forced reroutingdoes, but a situation in which there is no real necessity to performrerouting as fast as possible, because both routes of the connection arestill in use.

Controlled rerouting from the route A-B to the route a-b is started, forexample, when the primary route a-b is in order again or when thenetwork operator wants to disable the route A-B for some other reason.In a typical situation, the primary route is the fastest one of thealternative routes and, thus, it is always used when it is in order, ifpossible. Therefore, even the example of controlled rerouting describedhere concerns a return to the primary route a-b.

If node 1, for instance, is the first one to start controlled rerouting,it starts buffering the data packets to be transmitted to the virtualconnection and notifies the opposite end (for example, via the route tobe enabled) that it is enabling the route a→b. Thus, it is advantageousto the invention that all these management messages concern just theroute on which they travel. In this case, the different ends need nothave any common route identification data.

When node 4 is satisfied with this new route, node 4 starts bufferingthe traffic, too, and transmits a corresponding notice to node 1. Inconflict situations, in which the different ends of the virtualconnection intend to transfer traffic to different routes, theconception of one node is dominating, in the manner described above.When the nodes have agreed upon the new active route, they both send toeach other special return-from-route notices.

The return-from-route notice is sent to that route (A-B) of the virtualconnection which is to be disabled, routed like ordinary data packets sothat it will not overtake them. The return-from-route notice istransmitted to the route to be disabled after the data packets. When anode receives a return-from-route notice from the route of the virtualconnection, it sends an acknowledgement via the same route to thesender. Upon receiving this acknowledgement about returning from theroute, the node can be sure of the arrival of all the data packets fromthe route of the virtual connection to the opposite end unless they havebeen destroyed on the way.

When node 1 has received a return-from-route acknowledgement from theroute A-B to be disabled, it stops buffering the data packets to betransmitted to the virtual connection and transmits the buffered datapackets to a new active route a→b. When node 4 has also received areturn-from-route acknowledgement and acted correspondingly, the trafficas a whole is transferred to the route a-b that messages are not lost ortheir order is not changed because of rerouting.

According to one preferred embodiment of the invention, it is advisableto use time supervision in controlled rerouting as a further check incase a return-from-route acknowledgement does not arrive. Afterexpiration of the time-out period, the buffering of traffic is stopped,which means that the time-out period must be of a long duration so thatthe probability of the wrong order of the data packets will be verysmall. On the other hand, the time supervision period be so short thatit is very improbable that the ability of the node to buffer (dependingon the length of the buffers in use) will end during the period.

The method of the invention makes sure that traffic is not receivedsimultaneously from different routes of the virtual connection. Themethod can possibly be complemented so that the data packets are notaccepted (even if received) from other routes after the nodes have cometo an agreement on the route to be used. Thus, it is further ensuredthat the data packets do not arrive in a wrong order, but this will leadto a traffic blackout, for example, when a notice of rerouting gets lostbecause of a transmission error. Therefore, a better alternative is totransmit all the received data packets on to the subscriber.

FIGS. 3-5 show, as an example, the essential parts of state machineswith which both forced rerouting and controlled rerouting can beperformed (fast forced rerouting not being shown).

FIG. 3 shows the operation of a state machine concerning a route in anode. One route has four main states which are marked as follows: ROUTEIN USE, ROUTE IN RESERVE, ROUTE AWAITS ACKNOWLEDGEMENT, and ROUTEFAULTY. Transitions between these states are marked with reference signsA-M. Transitions to the state ROUTE IN USE from the states ROUTE AWAITSACKNOWLEDGEMENT or ROUTE IN RESERVE can have two stages, D+I or J+I.Transitions caused by messages received by the node and the possiblemessages sent as a result of these transitions are described below. Thereceived messages are shown by the letter R and a colon in front of them(R:). The messages to be sent are shown similarly by the letter S (S:).The messages can be any messages with the respective meanings describedbelow, and do not necessarily have to come from the opposite node.Message can come from farther away or from the network management, forinstance. In connection with the messages to be sent, the destination ofa respective message is indicated after the letter S, separated by aslash. If the letter S is in parenthesis, it means that the respectivemessage is not sent every time, but only when needed.

Transition A

R: "Testing failed",

Transition B

R: "Even the last fault has been removed from the route",

S/opposite end: "Route in order here, how about there?"

Transition C

R: "Testing failed",

R: "Route faulty at my own end",

R: "Fault on the route",

R: "Fault at the opposite end",

(S)/alternative route: "Get active at once".

All four received messages are alternative, and even one of them causesa transition from the state ROUTE IN USE to the state ROUTE FAULTY. Incase of the first two messages, a message "Our end faulty" is sent whennecessary. At Transition C, traffic is stopped (a fault situation).

Transition D

R: "Route in order also at the obeying end".

Transition E (internal transition in the state ROUTE IN USE)

R: "Possible forced rerouting",

S: "Start testing".

Transition F (internal transition in the state ROUTE IN USE)

R: "Testing in order",

S: "Stop buffering".

Transition G

R: "Get active at once",

S/opposite end: "Traffic onto this route",

S: "Stop buffering".

When this transition occurs, the node starts the traffic and sends therespective message.

Transition H

R: "Return-from-route",

S/opposite end: "Return-from-route".

Transition I

S/opposite end: "Traffic onto this route",

S: "Start buffering",

S/former route: "Return-from-route".

Transition J

R: "The opposite end priorities also allow enabling the route",

R: "The dominating end uses this route".

Transition K

R: "Route also in order at the dominating end",

(S)/opposite end: "Our priorities allow enabling the route".

Transition L (internal transition in the state ROUTE IN RESERVE)

R: "Return-from-route acknowledgement",

S: "Stop buffering".

Instead of a return-from-route acknowledgement, the transition can becaused by the expiration of the time-out period.

Transition M (internal transition in the state ROUTE IN RESERVE)

R: "The obeying end uses this route",

S/active route: "Possible forced rerouting",

S: "Start buffering".

Forced rerouting and controlled rerouting comprise of the transitionsdescribed above. For example, the above-described controlled reroutingstarted by one node can include, for instance, transitions H and L (theroute to be disabled) and B, K, J and I (the route to be enabled/obeyingnode) or B, D and I (the route to be enabled/dominating node). Thepriorities in the messages refer to the priority that is configured tothe respective route in the node.

When the nodes detect a fault and start a forced rerouting at the sametime, nodes make the transitions C (the route to be disabled) and G (theroute to be enabled) only. If the dominating node does not detect thefault before the obeying node notifies of the rerouting, the dominatingnoder resorts (on the route to be disabled) the transitions M, E and C.In a conflict situation, in which the dominating node detects after thetransitions M and E that the route is in order, it carries out only aninternal transition F and the transitions C and G will not be made.

FIG. 4 shows a buffering automation (a state machine for buffering) thathas two main states: FREE and BUSY. When a node receives a messagesaying "start buffering", the automation is transferred from the stateFREE to the state BUSY, and the traffic of the data connection will bewritten in the buffer. When a message received in the state BUSY says"stop buffering," or after the expiration of the time-out period, asdescribed above, the buffered traffic is transmitted to the dataconnection via the route in use. After this, the traffic will not bewritten in the buffer, and a transition is made to the state FREE.

FIG. 5 shows a testing automation of the route (a state machine forroute testing) that also has two main states: ROUTE NOT TESTED and ROUTEBEING TESTED. When the node receives a message saying "start testing",the automation is transferred to a testing state and a message "Iseverything in order?" is sent to the opposite end. There are two ways toleave the testing state for another main state. The transition is madein the one way if a message "at the opposite end the route is in order"is received, and then, a message "testing in order" is sent and atransition is made to the state ROUTE NOT TESTED. The same transitioncan be made in the other way by receiving in the testing state, either amessage "fault at the opposite end" or a message "fault on the route" orafter a time-out. At the same time, a message "testing failed" is sent.

Although the invention was above explained with reference to theexamples of the accompanying drawings, it is clear that the invention isin no way restricted thereto, but it can be modified within the scope ofthe inventive concept disclosed above and in the appended claims. As wasmentioned above, the arrangement of the invention does not, for example,require of the internal structure of the node anything else but theability to buffer data. Therefore, the internal structure of the nodecan be accomplished in many ways known per se. The buffering itself canalso be carried out in different ways; the outgoing or incoming data orboth can be buffered. The most natural procedure is, however, to bufferthe outgoing data. Also, the operation of the state automations, forexample, can vary in many ways although they realize the essential ideaof the invention; only one example of their operation is shown above.

I claim:
 1. A method for rerouting a packet-mode data connection in anetwork, in which, between a first node serving a first subscriber and asecond node serving a second subscriber, at least two alternativelyuseful bi-directional communication routes are potentially available foruse as alternatives to one another, these comprising at least a firstroute and a second route, and both of said nodes being capable ofbuffering data packets which a respective one of said subscribersintends to have transmitted by a respective one of said nodes, to therespective other of said subscribers via the respective other of saidnodes, comprising the steps of:while in operation for at least one ofsending and receiving data packet traffic to and from one another forrespective subscribers, over a respective one of said routes which iscurrently in use, said first and second nodes listening not only to therespective route in use, but also to a at least another of said routesas a respective alternative route for use as an alternative to said oneof said routes which is currently in use; either or both of said nodes,in connection with determining to change from sending packet datatraffic to the respective other of said nodes via the respective saidone of said routes which is currently in use, to a respective alternateroute, sending a corresponding message about rerouting to the respectiveother of said nodes via said respective alternate route; and therespective other said nodes, based on the first to occur of reception ofa respective said message about rerouting and a practice thereby of saiddetermining, participating with the respective other of said nodes in arerouting situation which, upon completion, results in said first andsecond nodes both being in operation for at least one of sending andreceiving data packet traffic to and from one another over a respectivealternate one of said routes, said determining is practiced by one ofsaid nodes, upon detecting or being informed of a fault in said one ofsaid routes which is currently in use, and said message about reroutingtherefore being of a type concerning forced rerouting involvingbuffering, the respective other of said nodes, upon receiving saidmessage about rerouting,(a) ceasing sending packet data traffic to therespective other of said nodes on said respective one of said routes,and, instead, buffering such traffic; (b) testing the condition of saidrespective one of said routes; and (c) upon finding said condition ofsaid respective one of said routes to be faulty, ceasing buffering ofsuch traffic, and initiating sending of such traffic, starting with thatwhich was buffered, to the respective other of said nodes using arespective alternate of one of said routes.
 2. The method of claim 1,wherein:said sending and receiving data packet traffic is constituted bysending and receiving frames by frame relay.
 3. The method of claim 1,wherein:said determining is practiced by each of said nodes, upondetecting or being informed of a fault in said one of said routes whichis currently in use, each said message about rerouting therefore beingof a type concerning forced rerouting.
 4. A method for rerouting apacket-mode data connection in a network, in which, between a first nodeserving a first subscriber and a second node serving a secondsubscriber, at least two alternatively useful bi-directionalcommunication routes are potentially available for use as alternativesto one another, these comprising at least a first route and a secondroute, and both of said nodes being capable of buffering data packetswhich a respective one of said subscribers intends to have transmittedby a respective one of said nodes, to the respective other of saidsubscribers via the respective other of said nodes, comprising the stepsof:while in operation for at least one of sending and receiving datapacket traffic to and from one another for respective subscribers, overa respective one of said routes which is currently in use, said firstand second nodes listening not only to the respective route in use, butalso to a at least another of said routes as a respective alternativeroute for use as an alternative to said one of said routes which iscurrently in use; either or both of said nodes, in connection withdetermining to change from sending packet data traffic to the respectiveother of said nodes via the respective said one of said routes which iscurrently in use, to a respective alternate route, sending acorresponding message about rerouting to the respective other of saidnodes via said respective alternate route; and the respective other saidnodes, based on the first to occur of reception of a respective saidmessage about rerouting and a practice thereby of said determining,participating with the respective other of said nodes in a reroutingsituation which, upon completion, results in said first and second nodesboth being in operation for at least one of sending and receiving datapacket traffic to and from one another over a respective alternate oneof said routes, wherein each said message about rerouting, as sent,contains information as to the position of the node which sent thatmessage in a pre-established hierarchy of nodes which also includes therespective other of said nodes; and said rerouting situation ispracticed by said first and second nodes so as to result in rerouting toa common alternative to said one of said routes, that results eitherfrom both of said nodes independently selecting that alternative route,or, upon both of said nodes, by prearrangement, the respectivealternative route selected by the one of said nodes having therelatively higher position in said hierarchy being put into use for saidrerouting by both of said nodes.
 5. The method of claim 4, wherein:saidsending and receiving data packet traffic is constituted by sending andreceiving frames by frame relay.
 6. The method of claim 4, wherein:saiddetermining is practiced by each of said nodes, upon detecting or beinginformed of a fault in said one of said routes which is currently inuse, each said message about rerouting therefore being of a typeconcerning forced rerouting.
 7. The method of claim 4, wherein:therespective other of said nodes, upon receiving said message aboutrerouting, and having a lower position in said hierarchy than the nodewhich sent said message,(a) ceasing sending packet data traffic to therespective other of said nodes on said respective one of said routes,and, instead, buffering such traffic; (b) sending the respective otherof said nodes a return-from-route notice; and (c) in response toreceiving from the respective other of said nodes an acknowledgement ofreceipt of said return-from-route notice, ceasing buffering of suchtraffic, and initiating sending of such traffic, starting with thatwhich was buffered, to the respective other of said nodes using therespective alternate one of said routes.
 8. A method for rerouting apacket-mode data connection in a network, in which, between a first nodeserving a first subscriber and a second node serving a secondsubscriber, at least two alternatively useful bi-directionalcommunication routes are potentially available for use as alternativesto one another, these comprising at least a first route and a secondroute, and both of said nodes being capable of buffering data packetswhich a respective one of said subscribers intends to have transmittedby a respective one of said nodes, to the respective other of saidsubscribers via the respective other of said nodes, comprising the stepsof:while in operation for at least one of sending and receiving datapacket traffic to and from one another for respective subscribers, overa respective one of said routes which is currently in use, said firstand second nodes listening not only to the respective route in use, butalso to a at least another of said routes as a respective alternativeroute for use as an alternative to said one of said routes which iscurrently in use; either or both of said nodes, in connection withdetermining to change from sending packet data traffic to the respectiveother of said nodes via the respective said one of said routes which iscurrently in use, to a respective alternate route, sending acorresponding message about rerouting to the respective other of saidnodes via said respective alternate route; and the respective other saidnodes, based on the first to occur of reception of a respective saidmessage about rerouting and a practice thereby of said determining,participating with the respective other of said nodes in a reroutingsituation which, upon completion, results in said first and second nodesboth being in operation for at least one of sending and receiving datapacket traffic to and from one another over a respective alternate oneof said routes, wherein said determining is practiced by one of saidnodes, upon detecting or being informed of a fault in said one of saidroutes which is currently in use, and said message about reroutingtherefore being of a type concerning forced rerouting involvingbuffering, said one of said nodes, upon practicing said determining tochange, sending as said message about rerouting a message of a typeconcerning forced rerouting involving no buffering, and, withoutbuffering to await receipt of an acknowledgement immediately changes tosending packet data traffic to the respective other of said nodes via arespective said alternate route; and the respective other of said nodes,upon receiving said message about rerouting, ceasing sending packet datatraffic to the respective other of said nodes on said respective one ofsaid routes, and, instead, without buffering such traffic, initiatingsending of such traffic to the respective other of said nodes, using therespective alternate one of said routes.
 9. The method of claim 4,wherein:said sending and receiving data packet traffic is constituted bysending and receiving frames by frame relay.
 10. The method of claim 4,wherein:said determining is practiced by each of said nodes, upondetecting or being informed of a fault in said one of said routes whichis currently in use, each said message about rerouting therefore beingof a type concerning forced rerouting.
 11. A method for rerouting apacket-mode data connection in a network, in which, between a first nodeserving a first subscriber and a second node serving a secondsubscriber, at least two alternatively useful bi-directionalcommunication routes are potentially available for use as alternativesto one another, these comprising at least a first route and a secondroute, and both of said nodes being capable of buffering data packetswhich a respective one of said subscribers intends to have transmittedby a respective one of said nodes, to the respective other of saidsubscribers via the respective other of said nodes, comprising the stepsof:while in operation for at least one of sending and receiving datapacket traffic to and from one another for respective subscribers, overa respective one of said routes which is currently in use, said firstand second nodes listening not only to the respective route in use, butalso to a at least another of said routes as a respective alternativeroute for use as an alternative to said one of said routes which iscurrently in use; either or both of said nodes, in connection withdetermining to change from sending packet data traffic to the respectiveother of said nodes via the respective said one of said routes which iscurrently in use, to a respective alternate route, sending acorresponding message about rerouting to the respective other of saidnodes via said respective alternate route; and the respective other saidnodes, based on the first to occur of reception of a respective saidmessage about rerouting and a practice thereby of said determining,participating with the respective other of said nodes in a reroutingsituation which, upon completion, results in said first and second nodesboth being in operation for at least one of sending and receiving datapacket traffic to and from one another over a respective alternate oneof said routes, wherein said determining is practiced by one of saidnodes, upon detecting or being informed of a reason other than a faultin said one of said routes which is currently in use, and said messageabout rerouting thereby being of a type concerning controlled reroutinginvolving buffering; and said rerouting situation comprises:(a) both ofsaid nodes buffering packet data traffic intended to be sent to oneanother, while coming to an agreement as to which of said alternativeroutes to switch to as an alternative route as an agreed alternate routeto use for exchanging packet data traffic; (b) both of said nodessending return-from-route-notices to one another on said one of saidnodes which is currently in use; (c) each of said nodes acknowledging tothe respective other of said nodes reception of the respective one ofsaid return-from-route notices; and (d) each of said nodes, in responseto its receipt of the respective said acknowledging, ceasing its saidbuffering, and sending packet data traffic, beginning with that whichwas buffered, to the respective other of said nodes, via said agreedalternate route.
 12. The method of claim 11, wherein:said sending andreceiving data packet traffic is constituted by sending and receivingframes by frame relay.
 13. The method of claim 11, wherein:saiddetermining is practiced by each of said nodes, upon detecting or beinginformed of a fault in said one of said routes which is currently inuse, each said message about rerouting therefore being of a typeconcerning forced rerouting.
 14. The method of claim 11, wherein:both ofsaid nodes practice said sending of return-from-route notices, byrouting their respective said notices after ordinary data packets inrespective data packet traffic.
 15. The method of claim 11, wherein:eachsaid message about rerouting, as sent, contains information as to theposition of the node which sent that message in a pre-establishedhierarchy of nodes which also includes the respective other of saidnodes; and said rerouting situation is practiced by said first andsecond nodes so as to result in rerouting to a common alternative tosaid one of said routes, that results either from both of said nodesindependently selecting that alternative route, or, upon both of saidnodes, by prearrangement, the respective alternative route selected bythe one of said nodes having the relatively higher position in saidhierarchy being put into use for said rerouting by both of said nodes.16. A method for rerouting a packet-mode data connection in a network,in which, between a first node serving a first subscriber and a secondnode serving a second subscriber, at least two alternatively usefulbi-directional communication routes are potentially available for use asalternatives to one another, these comprising at least a first route anda second route, and both of said nodes being capable of buffering datapackets which a respective one of said subscribers intends to havetransmitted by a respective one of said nodes, to the respective otherof said subscribers via the respective other of said nodes, comprisingthe steps of:while in operation for at least one of sending andreceiving data packet traffic to and from one another for respectivesubscribers, over a respective one of said routes which is currently inuse, said first and second nodes listening not only to the respectiveroute in use, but also to a at least another of said routes as arespective alternative route for use as an alternative to said one ofsaid routes which is currently in use; either or both of said nodes, inconnection with determining to change from sending packet data trafficto the respective other of said nodes via the respective said one ofsaid routes which is currently in use, to a respective alternate route,sending a corresponding message about rerouting to the respective otherof said nodes via said respective alternate route; and the respectiveother said nodes, based on the first to occur of reception of arespective said message about rerouting and a practice thereby of saiddetermining, participating with the respective other of said nodes in arerouting situation which, upon completion, results in said first andsecond nodes both being in operation for at least one of sending andreceiving data packet traffic to and from one another over a respectivealternate one of said routes, wherein said determining is practiced byone of said nodes, upon detecting or being informed of a reason otherthan a fault in said one of said routes which is currently in use, andsaid message about rerouting thereby being of a type concerningcontrolled rerouting involving buffering; and said rerouting situationcomprises:(a) both of said nodes buffering packet data traffic intendedto be sent to one another, while coming to an agreement as to which ofsaid alternative routes to switch to as an alternative route as anagreed alternate route to use for exchanging packet data traffic; (b)both of said nodes sending return-from-route-notices to one another onsaid one of said nodes which is currently in use; (c) each of said nodesacknowledging to the respective other of said nodes reception of therespective one of said return-from-route notices; and (d) each of saidnodes, in response to whichever first occurs of its receipt of therespective said acknowledging and the expiration of a certainpredetermined waiting time period, ceasing its said buffering, andsending packet data traffic, beginning with that which was buffered, tothe respective other of said nodes, via said agreed alternate route. 17.The method of claim 16, wherein:each said message about rerouting, assent, contains information as to the position of the node which sentthat message in a pre-established hierarchy of nodes which also includesthe respective other of said nodes; and said rerouting situation ispracticed by said first and second nodes so as to result in rerouting toa common alternative to said one of said routes, that results eitherfrom both of said nodes independently selecting that alternative route,or, upon both of said nodes, by prearrangement, the respectivealternative route selected by the one of said nodes having therelatively higher position in said hierarchy being put into use for saidrerouting by both of said nodes.
 18. The method of claim 16,wherein:said sending and receiving data packet traffic is constituted bysending and receiving frames by frame relay.
 19. The method of claim 16,wherein:said determining is practiced by each of said nodes, upondetecting or being informed of a fault in said one of said routes whichis currently in use, each said message about rerouting therefore beingof a type concerning forced rerouting.